Problem Solving in Computer Science : Week 10 Scribe on duty : Hossein Hojjat

In this section we review the concept of transactional memories from [1]. A traditional way to make threads communicating and synchronizing with each other is by using locks and condition variables. These methods of synchronization are fundamentally flawed, since they do not compose well. Concurrent programs based on locking are also hard to follow and debug. In many cases, programming with locks sounds to be absurdly hard, e.g. for a scalable doubleended queue when the queue size is small. The problem in a sequential settings is easy to solve, but when the calls become concurrent it turns out to be an academic challenge to solve it. The transactional memory approach is an easy way to look at the synchronization problem. Similar to databases, we use transactions in order to access the memory. A set of instructions are wrapped with an atomic command to show that they obey the “all or nothing” semantics. So whenever an exception occurs in the middle of executing a transaction none of the instructions in the transaction can affect the state of the program. A direct consequence of using transactions is to avoid deadlocks, since nowhere during this approach something is locked. An effective way to make transactions is to use optimistic concurrency. Here, any access to the memory is logged into a transaction log. After the transaction finished, it is the duty of the system to commit all the reads and writes in the transaction log into the memory in one step. If the system could not commit the log, nothing would be changed in the memory. One has to merely re-run the transaction so that the changes take effect. So, instead of using condition variables to wake up threads, the transactions are run again and again until they successfully finish. The main problem with transactional memories is their run-time cost. In transactional memories most of the synchronizing burden is put on the system whereas the programming task becomes easier.